Proper error handling is missing here (500 Internal Server Error).

@pellared Isn't it refering to this line -
if rolls is set to an invalid input (not a number): status code 400 and {"status": "error", "message": "Parameter rolls must be a positive integer"} ?

I mean if the json encoding fails then it is an internal server error.

I thought that the chances of static map encoding failure is very less. Can I handle it like this?

if err != nil {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusBadRequest)

    msg := "Parameter rolls must be a positive integer"
    resp := map[string]string{
        "status":  "error",
        "message": msg,
    }

    if encErr := json.NewEncoder(w).Encode(resp); encErr != nil {
        logger.ErrorContext(r.Context(), "failed to write error JSON", "error", encErr)
        http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
        return
    }

    logger.WarnContext(r.Context(), msg)
    return
}

The HTTP status code should be set before writing the response body. Setting WriteHeader after json.NewEncoder(w).Encode() has already written data will have no effect, as headers are sent with the first write. Move the WriteHeader call before the Encode call.

The HTTP status code should be set before writing the response body. Setting WriteHeader after json.NewEncoder(w).Encode() has already written data will have no effect, as headers are sent with the first write. Move the WriteHeader call before the Encode call.

[nitpick] Inconsistent logging format compared to the uninstrumented version. The uninstrumented version logs request details like "INFO: GET /rolldice?rolls=5 -> 200 OK" (line 50), while the instrumented version logs a generic message. Consider maintaining similar informative logging for consistency across both examples.

The error returned by resource.New() is being silently ignored. This could lead to using a nil or incomplete resource, potentially causing issues with telemetry data. Either handle the error properly or at minimum log it if you intend to continue with a partial resource.

The counter is being incremented by 1 regardless of the number of rolls performed. This doesn't accurately represent the total number of dice rolls. Consider incrementing by the number of actual rolls: rollCnt.Add(ctx, int64(rolls), metric.WithAttributes(rollsAttr))

Missing Content-Type header before writing response. The handler should set w.Header().Set("Content-Type", "application/json") before calling writeJSON to properly indicate the response format, especially for error responses.

Missing Content-Type header before writing response. The handler should set w.Header().Set("Content-Type", "application/json") before calling writeJSON to properly indicate the response format, especially for error responses.

[nitpick] The description "The last rolls value observed" is unclear. Consider clarifying what "rolls value" means, e.g., "The number of dice rolled in the most recent request" to better describe what this gauge represents.

[nitpick] The log message "Some player rolled a dice" is generic and doesn't add useful information beyond what's already logged in lines 105-108. Consider either making this message more specific (e.g., include the request status or outcome summary) or removing it to avoid redundant logging.